Week2 - 你有沒有想過，到底Server是如何「同時處理多個requests」的？ - Node.js篇 [鼠年全馬鐵人挑戰-NodeJs轉Golang的爆炸之旅系列]

w3hexschool golang go javascript

髒桶子 York Lin 2020-02-22 14:17:36 ‧ 7300 瀏覽

分享至

文章也同時發表於medium(｀・ω・´)”

某次我跟partner小明發生了一件趣事，不知大家是否也有以下相似的經驗：

小明：你的server好像卡住了，client這邊打requests要等很久耶！

我：ㄜ...我記得Node.js因為有Event queue與Event loop非同步模型，所以是非阻塞IO的server，這好像就是我要一直要用callback的原因，整個server那麼多callback應該是不會被多個requests而阻塞吧？

小明：喔喔，這應該就是Node.js適合IO-bound的原因吧，但聽說還有CPU-bound，CPU是不是也有可能阻塞啊？

我：？？？

小明：我說...

等等！好多專有名詞你到底在公蝦咪

一開始聽到這些名詞，我矇圈了許久。

我們現在來介紹這些名詞到底能辦到什麼，讓大家先有個概念。

大家要先有一個認知就是，Node.js是單執行緒-single thread，所以做什麼事情都沒辦法使用影分身之術多執行緒-multi thread來多工，但網路的世界肯定是多工的啊！

舉個例子：「如果FB網頁載入一張圖片，聊天框就不能動了」，那麼大家肯定都在也不用FB，~~大家都視力2.0~~，而Node.js怎麼解決這件事呢？

以下就用麥當當點餐情境配合圖片來解釋：

讓requests可等候的-Event queue：

顧客(request)光顧麥當當時，需要有一個空間可以等候餐點，而Event queue就是此空間。

負責傳遞餐點task的-Event loop：

面對大量個顧客，Node.js必須要有快速處理餐點的能力，此時靠的就是櫃檯Event loop(這間麥當當只有一個櫃檯)，負責把顧客的餐點需求告知給廚房，大廚們就會「自行分配」到底誰要處理漢堡、薯條等等。

你們廚房繼續做，我繼續為顧客點餐的-非同步：

而當廚房餐點正在製作時，櫃檯人員還是能繼續服務顧客點餐，在處理點餐時，大廚們的餐點好了通知櫃檯(callback)，這時櫃檯會停下手邊工作，把餐點送給客人，再繼續原本的點餐服務。

這代表了Node.js不會一直處理顧客點餐的服務，當餐點好了就會先暫停手邊工作而去送餐，這讓執行的順序是非同步的

因櫃檯與廚房都好好合作，所以排隊不會塞車的-非阻塞IO(non-blocking IO)

大家可以發現到，就算櫃檯始終只有一個，但有了大廚們的配合，還是可以很快地處理完這些餐點，可以想想看，如果沒有大廚們，全都靠櫃檯人員負責點餐跟煮菜，那麥當當應該直接排隊排到馬路上。

所以套回Node.js上，因為Node.js很適合這樣與「不同周邊互動」的情境，例如：其他server、資料庫、文件溝通時，所以他很適合密集的接受一連串的點餐，「不會因溝通而停止自己手邊的工作」即是非阻塞IO，因此我們說「Node.js適合IO-bound(IO密集型)操作」。

於是麥當當又過了和平沒有塞車的一天，直到...

櫃檯人員點餐處理太麻煩而塞車的-阻塞CPU(blocking CPU)

但是，如果今天賣當當規定，櫃檯要先與顧客打五場任天堂明星大亂鬥才能點餐，那櫃檯肯定會因這五場遊戲而「卡住」了所有事情，其他顧客點餐要等很久，而大廚在廚房也沒事做，因為櫃檯打遊戲太拖台錢了。

櫃檯沒辦法分身(多執行緒)去應付點餐，所以我們才會說「Node.js不適合CPU-bound(CPU密集型)操作」。

大致上理解一點了，但有沒有一些範例？

我這邊準備了Node.js 兩個server與test script來解釋，

完整範例：Github link

Server分別為：

Node.js server：主server
Sleep server：模擬耗時API的server，對任何requests都會故意睡5秒再回response

首先是測試Node.js的強項非阻塞IO的部分，

我們用testIO.js發送多個requests至主server，
而主server再去向Sleep server發出請求，此動作即是非同步的。

// server.js
async function request () {
  console.log("let't go")
  await rp('http://localhost:9999/sleep')
  console.log('done')
}

app.get('/io', async function (req, res) {
  await request()
  res.send('Hello World!');
})

// testIO.js
async function request () {
    console.log("let't go")
    await rp('http://localhost:3000/io')
    console.log('done')
}

(async () => {
    await Promise.all([
        request(),
        request(),
        request(),
        request(),
        request(),
        request(),
    ])
})()

在測試腳本執行下去之後會得到此結果：

腳本的全部requests發出後，會在約五秒後，一次把responses都拿回來，在這五秒到底發生了什麼事呢？

我們用時序圖來看看

我們可以發現，在藍箭頭處，主server並沒有停留在等待SleepServer的回應，而是緊接著處理下一個request，

假如主server沒有非阻塞IO的特性，會等待SleepServer回應才處理下個request，就會變成下圖

處理的時間會直接變成三倍，因為主server與SleepServer溝通時都在等待SleepServer，完完全全的被「阻塞」了，

這就是非阻塞IO與阻塞IO實務上的狀況

再來是測試Node.js的會阻塞CPU的部分，

testCPU.js也發送多個requests至主server，
而主server上面是重複計算x++十萬次並打印出他，

// server.js
async function request () {
  console.log("let't go")
  await rp('http://localhost:9999/sleep')
  console.log('done')
}

app.get('/cpu', function (req, res) {
    let x = 0
    while (x <= 100000){
        console.log(x)
        x++
    }
    res.send('Hello World!');
});

// testCPU.js
async function request () {
    console.log("let't go")
    await rp(`http://localhost:${host}/cpu`)
    console.log('done')
}

(async () => {
    await Promise.all([
        request(),
        request(),
        request(),
        request(),
        request(),
        request(),
    ])
})()

執行起來會發現，done是一個一個出現的，主server每打印完十萬次才會回應給腳本，